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Abstract 

As nuclear power expands, technical, economic, political, and environmental analyses of nuclear fuel cycles 
by simulators increase in importance. To date, however, current tools are often fleet-based rather than 
discrete and restrictively licensed rather than open source. Each of these choices presents a challenge to 
modeling fidelity, generality, efficiency, robustness, and scientific transparency. The Cyclus nuclear fuel 
cycle simulator framework and its modeling ecosystem incorporate modern insights from simulation science 
and software architecture to solve these problems so that challenges in nuclear fuel cycle analysis can be 
better addressed. A summary of the Cyclus fuel cycle simulator framework and its modeling ecosystem are 
presented. Additionally, the implementation of each is discussed in the context of motivating challenges in 
nuclear fuel cycle simulation. Einally, the current capabilities of Cyclus are demonstrated for both open 
and closed fuel cycles. 

Keywords: nuclear fuel cycle, simulation, agent based modeling, nuclear engineering, object orientation, 
systems analysis 


1. Introduction 

As nuclear power expands, technical, economic, 
political, and environmental analyses of nuclear fuel 
cycles by simulators increase in importance. The 
merits of advanced nuclear technologies and fuel 
cycles are shaped by myriad physical, nuclear, chem¬ 
ical, industrial, and political factors. Nuclear fuel 
cycle simulators must therefore couple complex mod¬ 
els of nuclear process physics, facility deployment, 
and material routing. 

Indeed, the cardinal purpose of a dynamic nuclear 
fuel cycle simulator is to calculate the time- and 
facility-dependent mass flow through all or part 
the fuel cycle. Dynamic nuclear fuel cycle analysis 
more realistically supports a range of simulation 
goals than static analysis [T]. Historically, dynamic 
nuclear fuel cycle simulators have calculated fuel 
cycle mass balances and performance metrics derived 
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from them using software ranging from spreadsheet- 
driven flow calculators to highly specialized system 
dynamics modeling platforms. 

To date, current tools are typically distributed 
under restrictive rather than open source licenses, 
having been developed in industrial contexts or using 
commercial software platforms. Additionally, having 
often been developed for customized applications, 
many possess inflexible architectures, never having 
been designed to enable new features or extensions. 
Finally, many model only fleet-level dynamics of fa¬ 
cilities and materials rather than discrete resolution 
of those individual agents and objects. When the 
DOE-NE Fuel Cycles Technologies Systems Analy¬ 
sis Campaign developed requirements necessary in 
a next generation fuel cycle simulator, three main 
failure modes were associated with those software 
choices. First, they discourage targeted contribu¬ 
tion and collaboration among experts. Next, they 
hobble efforts to directly compare modeling method¬ 
ologies. Finally, they over-specialize, rendering most 
tools applicable to only a subset of desired Simula- 
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tion fidelities, scales, and applications. Those three 
constraints were identified as presenting significant 
challenges to modeling fidelity, generality, efficiency, 
robustness, and scientific transparency in the field 
of fuel cycle analysis [5]. 

The Cyclus nuclear fuel cycle simulator frame¬ 
work and its modeling ecosystem, the suite of agents 
and other physics plug-in libraries compatible with 
it, incorporate modern insights from simulation sci¬ 
ence and software architecture to solve these prob¬ 
lems. These modern methods simultaneously enable 
more efficient, accurate, robust, and validated anal¬ 
ysis. This next-generation fuel cycle simulator is the 
result of design choices made to: 

• support access to the tool by fuel cycle analysts 
and other users, 

• encourage developer extensions, 

• enable plug-and-play comparison of modeling 
methodologies, 

• and address a range of analysis types, levels of 
detail, and analyst sophistication. 

Cyclus is a dynamic, agent-based model, which 
employs a modular architecture, an open develop¬ 
ment process, discrete agents, discrete time, and 
arbitrarily detailed isotopic resolution of materi¬ 
als. Experience in the broader field of systems 
analysis indicates that agent-based modeling en¬ 
ables more flexible simulation control than system 
dynamics, without loss of generality [S]. Further¬ 
more, openness allows cross-institutional collabora¬ 
tion, increases software robustness mis] , improves 
the strength and quality of results through peer re¬ 
view n El [510 [in], and cultivates an ecosystem of 
modeling options. This ecosystem is modular, being 
comprised of dynamically loadable, interchangeable, 
plug-in libraries of fuel cycle component process 
physics that vary in their scope, depth, and fidelity. 
This modularity allows users and developers to cus¬ 
tomise Cyclus to analyze the cases that are of 
interest to them rather than any custom application 
the simulator was originally developed to address. 
Additionally, that customizability allows users and 
developers to address those cases at the level of 
fidelity necessary for their application. The funda¬ 
mental concepts of the Cyclus nuclear fuel cycle 
simulator capture these modern insights so that 
novel challenges in nuclear fuel cycle analysis can 
be better addressed. 


1.1. Background 

Nuclear fuel cycle simulators drive research devel¬ 
opment and design (RD&D) by calculating ‘metrics’, 
quantitative measures of performance that can be 
compared among fuel cycle options. The feasibil¬ 
ity of the technology development and deployment 
strategies which comprise a fuel cycle option, the op¬ 
erational features of nuclear energy systems, the dy¬ 
namics of transitions between fuel cycles, and many 
other measures of performance can be expressed 
in terms of these metrics. For example, economic 
feasibility is often measured in levelized cost of elec¬ 
tricity (LCOE), a combination of fuel and operating 
costs normalized by electricity generation, while 
environmental performance might be measured by 
spent fuel volume, radiotoxicity, or mined uranium 
requirements. A meta-analysis of fuel cycle systems 
studies identified over two dozen unique quantitative 
metrics spanning economics and cost, environmen¬ 
tal sustainability and waste management impacts, 
safety, security and nonproliferation, resource ade¬ 
quacy and utilization, among others m- With few 
exceptions, these metrics are derived from mass bal¬ 
ances and facility operation histories calculated by 
a fuel cycle simulator. For example, where nuclear 
waste repository burden is derived from ejected fuel 
masses, water pollution or land use can be derived 
from facility operational histories (as in [T2]l. 

However, methods for calculating those metrics 
vary among simulators. Some model the system of 
facilities, economics, and materials in static equilib¬ 
rium, while other simulators capture the dynamics 
of the system. Similarly, while some simulators dis¬ 
cretely model batches of material and individual 
facilities, others aggregate facilities into fleets and 
materials into streams. Some simulators were de¬ 
signed to model a single aspect of the fuel cycle 
in great detail while neglecting others. For exam¬ 
ple, a simulator created for policy modeling might 
have excellent capability in economics while capa¬ 
bilities for tracking transformations in material iso¬ 
topics and the effects of isotopics on technology 
performance are neglected. The Code for Advanced 
Fuel Cycles Assessment (CAFCA)[T5] simulator 
is problem-oriented in this way, having elected to 
neglect isotopic resolution in favor of integral effects. 

Historically, domestic national laboratories have 
driven development and regulated the use of their 
own tools: the Verifiable Fuel Cycle Simulation 
Model (VISION) [T4|, Dynamic Model of Nuclear 
Development IDYMONDI |15j . and Nuclear Fuel 
Cycle Simulator (NFCSim)[T51 [TTj. Internationally, 
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other laboratories have created their own as well, 
such as Commelini-Sicard (COSI)[T8l [TU [20l [21] 
and ORION[22]. Finally, some simulators initiated 
in a national lab setting have been continued as 
propriety, industry-based simulators, such as Dy¬ 
namic Analysis of Nuclear Energy System Strategies 
(DANESS)[23]. Outside the national laboratories, 
researchers have created new nuclear fuel cycle sim¬ 
ulation tools when existing tools were not available 
or not sufficiently general to calculate their met¬ 
rics of interest. With limited access to the national 
laboratory tools and a need to customize them for 
research purposes, universities and private industry 
researchers have “reinvented the wheel” by devel¬ 
oping tools of their own from scratch and tailored 
to their own needs. Examples include CAECAj^l] 
and Dynamic Analysis of Nuclear Energy Systems 
Strategies (DESAE)|25l|26l[l2l- 


Cyclus emerged from a line of tools seeking to 
break this practice. Its precursor. Global Evaluation 
of Nuclear Infrastructure Utilization Scenarios (GE¬ 
NIUS) Version 1 [33 HE], originated within Idaho 
National Laboratory (INL) and sought to provide 
generic regional capability. Based on lessons learned 
from GENIUS Version 1, the GENIUS Version 2 
uniisD] simulator sought to provide more generality 
and an extensible interface to facilitate collabora¬ 
tion. The Cyclus project then improved upon the 
GENIUS effort by implementing increased modu¬ 
larity and encapsulation. The result is a dynamic 
simulator that treats both materials and facilities dis¬ 
cretely, with an architecture that permits multiple 
and variable levels of fidelity. Using an agent-based 
framework, the simulator tracks the transformation 
and trade of resources between autonomous regional 
and institutional entities with customizable behav¬ 
ior and objectives. Each of these concepts (agent- 
based, resource tracking, and regional as well as 
institutional entities) will be described in their own 
sections (sections 2.2[ 2.3.1 and 2.2.2 respectively). 
Together, they provide a capability for extension 
and reuse beyond that pursued by any existing fuel 
cycle simulator. 


This essential capability is absent in previous simula¬ 
tors where user customization and extensibility were 
not design objectives. While the modular and open 
architecture of Cyclus is necessary to meet these 
goals, it is not sufficient. Agent interchangeability is 
also required to facilitate direct comparison of alter¬ 
native modeling methodologies and facility concepts. 
With this concept at its core, Cyclus provides a 
platform for users to quickly develop the capabilities 
at a level of detail and validation necessary for their 
unique applications. Finally, Cyclus is applicable 
to a broader range of fidelities, scales, and applica¬ 
tions than other simulators, due to the flexibility 
and generality of its agent-based modeling (ABM) 
paradigm and discrete, object-oriented approach. 

This structure recognizes that specialists should 
utilize their time and resources in modeling the spe- 
cihc process associated with their area of expertise 
(e.g., reprocessing and advanced fuel fabrication), 
without having to create a model of the entire fuel 
cycle to serve as its host. Cyclus supports them 
by separating the problem of modeling a physics- 
dependent supply chain into two distinct compo¬ 
nents: a simulation kernel and archetypes that inter¬ 
act with it. The kernel is responsible for supporting 
the deployment and interaction logic of entities in 
the simulation. Physics calculations and customized 
behaviors of those entities are implemented within 
archetype classes. 

Ultimately, modeling the evolution of a physics- 
dependent, international nuclear fuel supply chain 
is a multi-scale problem which existing tools cannot 
support. They have either focused on macro effects, 
e.g., the fleet-level stocks and flows of commodities, 
or micro effects, e.g., the used-fuel composition of 
fast reactor fuel. Each focus has driven the devel¬ 
opment of specialized tools, rendering the task of 
answering questions between the macro and micro 
levels challenging within a single tool. In contrast, 
the open, extensible architecture and discrete object 
tracking of Cyclus allow the creation and inter¬ 
changeability of custom archetypes at any level of 
fidelity and by any fuel cycle analyst. 


1.2. Motivation 

The Cyclus paradigm enables targeted contribu¬ 
tion and collaboration within the nuclear fuel cycle 
analysis community to achieve two important goals: 
lower the barrier for users to include custom nuclear 
technologies and facility types in their fuel cycle 
analyses while improving the ability to compare sim¬ 
ulations with and without those custom concepts. 


1.2.1. Open Access and Development Practices 
The proprietary concerns of research institutions 
and security constraints of data within fuel cycle 
simulators often restrict access. Use of a simula¬ 
tor is therefore often limited to its institution of 
origin, necessitating effort duplication at other in¬ 
stitutions and thereby squandering broader human 
resources. License agreements and institutional ap- 
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proval are required for most current simulators (e.g. 
COSI6, DANESS, DESAE, EVOLCODE, FAM- 
ILY21, NFCSim)[3lj, including ORION, and VI¬ 
SION. Even when the source code is unrestricted, 
the platform on which it relies (e.g. VENSIM) is 
often restricted or costly. The MIT CAECA soft¬ 
ware, for example, relies on the commercially li¬ 
censed VENSIM product as a platform. Cyclus, 
on the other hand, is written in CH—I- for which 
freely available development tools and an open stan¬ 
dard are available. Further, Cyclus relies only on 
open source, freely available libraries. As such, it 
provides fully free and open access to all users and 
developers, foreign and domestic. 

Moreover, both technical and institutional aspects 
of the software development practices employed 
by the Cyclus community facilitate collaboration. 
Technically, Cyclus employs a set of tools com¬ 
monly used collaborative software development that 
reduce the effort required to comment on, test and 
ultimately merge individual contributions into the 
main development path. For many of the simula¬ 
tion platforms adopted by previous simulators, there 
were technical obstacles that impeded this kind of 
collaboration. Institutionally, Cyclus invites all 
participants to propose, discuss and provide input to 
the final decision making for all important changes. 

1.2.2. Modularity and Extensibility 

Modularity is a key enabler of extending the scope 
of fuel cycle analysis within the Cyclus framework. 
Changes that are required to improve the fidelity of 
modeling a particular agent, or to introduce entirely 
new agents, are narrowly confined and place no new 
requirements on the Cyclus kernel. Furthermore, 
there are few assumptions or heuristics that would 
otherwise restrict the algorithmic complexity that 
can be used to model the behavior of such agents. 

For example, most current simulators describe 
a finite set of acceptable cycle constructions (once 
through, single-pass, multi-pass). That limits the 
capability to create novel material flows and eco¬ 
nomic scenarios. The Cyclus simulation logic relies 
on a market paradigm, parameterized by the user, 
which flexibly simulates dynamic responses to pric¬ 
ing, availability, and other institutional preferences. 

This minimal set of mutual dependencies between 
the kernel and the agents is expressed through the 
dynamic resource exchange (DRE) that provides a 
level of flexibility that does not exist in other fuel 
cycle simulators. It creates the potential for novel 
agent archetypes to interact with existing archetypes 


as they enter and leave the simulation over time and 
seek to trade materials whose specific composition 
may not be known a priori. 

1.2.3. Discrete Facilities and Materials 

Many fuel cycle phenomena have aggregate 
system-level effects which can only be captured 
by discrete material tracking [2]. Cyclus tracks 
materials as discrete objects. Some current fuel 
cycle simulation tools such as COSI [ISJ [311 121], 
FAMILY21I1SI, GENIUS version 1, GENIUS ver¬ 
sion 2, NFCSim, and ORION also possess the ability 
to model discrete materials. However, even among 
these, the ability to model reactor facilities individu¬ 
ally is not equivalent to the ability to model distinct 
activities. COSI, for example, has some support for 
modeling reactors individually, but according to a 
recent benchmark [33) . it models many reactors op¬ 
erating in sync. That is, refuelling and discharging 
occur simultaneously for all reactors. While Cyclus 
allows this type of fleet-based aggregation of reactor 
behavior, Cyclus also enables operations in each 
facility to vary independently of any others in the 
simulation. 

Similarly, the ability to model disruptions (i.e. 
facility shutdowns due to insufficient feed material or 
insufficient processing and storage capacity) is most 
readily captured by software capable of tracking 
the operations status of discrete facilities |2|. Fleet- 
based models (e.g. VISION) are unable to capture 
this gracefully, since supply disruptions are modeled 
as a reduction in the capacity of the whole fleet. 
All of the software capable of discrete materials 
have a notion of discrete facilities, however not all 
handle disruption in the same manner. DESAE, for 
example, does not allow shutdown due to insufficient 
feedstock. In the event of insufficient fissile material 
during reprocessing, DESAE borrows material from 
storage, leaving a negative value [21] • The Cyclus 
framework does not dictate such heuristics. Rather, 
it provides a flexible framework on which either 
method is possible. 

A final benefit of the discreteness of facilities and 
materials is their power when combined. The abil¬ 
ity to track a material’s history as it moves from 
one facility to another is unique to Cyclus. While 
some current simulators track materials in discrete 
quanta, they do not necessarily preserve the identity 
of each quantum as the materials move around the 
fuel cycle. When coupled with Cyclus’ individ¬ 
ual facility modeling, this capacity becomes distinct 
from what other fuel cycle simulators are able to do. 
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So, while FAMILY21 and COSI can identify whether 
a batch being discharged from a reactor originated 
in mixed oxide (MOX) fabrication rather than fresh 
uranium oxide (UOX) fabrication, Cyclus can go 
further, tracking which of the fresh batches con¬ 
tained material from a particular discharged batch. 
By extension, Cyclus can also report which indi¬ 
vidual facilities the batch passed through and in 
which it originated. The ability to track a single 
material through the simulation, though it might 
be split, transmuted, or merged with other materi¬ 
als along the way, allows Cyclus to answer more 
data-rich questions that previous simulators have 
been unable to ask. For example, it allows precise 
tracking of specific material diversions, so queries 
about nonproliferation robustness in a facility can 
be levied either in the context of a single event or a 
series of nefarious acts. 

2. Methodology and Implementation 

A modular, agent-based modeling (ABM) ap¬ 
proach is ideal for modeling the coupled, physics- 
dependent supply chain problems involving material 
routing, facility deployment, and regional and insti¬ 
tutional hierarchies which arise in fuel cycle analysis. 
Additionally, the choice to build Cyclus on open 
source libraries in modern programming languages 
enables both remote and multiprocess execution 
on a number of platforms. This section begins by 
describing the general design features that make 
Cyclus both flexible and powerful: cluster-ready 
software and dynamically loadable libraries. The 
ABM framework is then described, focusing on its 
implementation and benefits in a fuel cycle con¬ 
text. A discussion of the time-dependent treatment 
of discrete resources follows, focusing on the DRE. 
Support for users and developers via the Cycamore 
library of archetypes and the experimental toolkit 
are also presented. Lastly, the methods for quality 
assurance are outlined. 

2.1. Modular Software Architecture 

The architecture of Cyclus allows developers to 
define nuclear fuel cycle processes independent of 
the simulation logic. To achieve this, agents are de¬ 
veloped which represent facilities, institutions, and 
regions comprising the nuclear fuel cycle. These 
agents are created using the Cyclus framework 
application programming interface (API), a set of 
functions and protocols which assist in agent devel¬ 
opment and specify how agents should be defined. 


This encapsulated ‘plug-in’ design choice provides 
two major benefits. First, analysts can take ad¬ 
vantage of the simulation logic API and archetype 
ecosystem when they apply Cyclus to their speciflc 
problem. A modeler can focus on creating or cus¬ 
tomizing nuclear facility, institution, resource, and 
toolkit models within their speciflc area of technical 
expertise. Second, because Cyclus uses a modular 
archetype approach, comparing two archetypes is 
straightforward. For example, if an analyst would 
like to compare the effect of using different mod¬ 
els to determine the input fuel composition for fast 
reactors, fuel fabrication archetypes can be devel¬ 
oped and interchanged while keeping the rest of the 
models used in the simulation fixed. 

2.1.1. Cluster-Ready Software 

Many fuel cycle simulators rely on commercial, off- 
the-shelf (COTS) and Windows-only software that 
limits performance on and compatibility with re¬ 
source computing infrastructures (e.g. cluster or 
cloud computing). This constrains the possible 
scope of simulations and increases the wall-clock 
time necessary to conduct parameterized sensitivity 
analyses and other multi-simulation studies. For 
example, large scale sensitivity analyses to quantify 
the dependence of fuel cycle outcomes are only fea¬ 
sible in a massively parallelized environment. To 
enable such research, Cyclus, is primarily written 
in C++ and relies on libraries supported by Linux 
and UNIX (including Ubuntu and OSX) platforms, 
which are flexible and support parallelization. 

Cyclopts [SI], a proof-of-principle Cyclus- 
enabled application on such a large compute system, 
uses UW-Madison’s HTCondor high-throughput 
computing (HTC) infrastructure to study DRE per¬ 
formance and outcomes. For example, an investi¬ 
gation of the effect of solution degeneracy, a com¬ 
monly observed phenomenon in scenarios with in¬ 
dividual facilities and basic (e.g., commodity-only) 
preference definitions, was performed for three dif¬ 
ferent fuel cycles: once-through, MOX fast reactor- 
thermal reactor cycles, and MOX-thorium oxide 
(ThOX) recycle in fast reactors-thermal reactor cy¬ 
cles. Objective coefficients were generated based on 
two factors: commodity-facility pairings and facility 
location. The population of the possible values of 
commodity-facility pairings is always small (0(10)). 
The size of the population of possible values of the 
location effect was investigated for values of zero, 
ten, and infinity (i.e., any real number). The study 
additionally included an investigation of problem- 
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scaling behavior in order to quantify the magnitude 
and rate-of-increase of DRE solution times as a func¬ 
tion of the simulation-entity population for each fuel 
cycle|3S]. In total, Cyclopts has run over 10^ jobs, 
comprising more than 60,000 compute hours. The 
HTC infrastructure has separately been utilized to 
run and collect information from full Cyclus simu¬ 
lations running in parallel on 10^ machines reliably 
for order 10® simulations. 


2.1.2. Dynamically Loadable Libraries 

The Cyclus architecture encourages efficient, tar¬ 
geted contribution to the ecosystem of archetype 
libraries. With Cyclus, a researcher can focus on 
generating an archetype model within their sphere 
of expertise while relying on the contributions of 
others to fill in the other technologies in the simula¬ 
tion. Similarly, individual developers may explore 
different levels of complexity within their archetypes, 
including wrapping other simulation tools as load¬ 
able libraries within Cyclus. 

Cyclus achieves this behavior by implementing 
generic APIs and a modular architecture via a suite 
of dynamically loadable plug-in libraries (pictured 
in Figure 2.1.21. By anticipating the possible classes 
of information required by the simulation kernel, 
the Cyclus APIs facilitate information passing be¬ 
tween the plug-in agents and the core framework. 
Though common in modern software architecture, 
such a plug-in paradigm has not previously been 
implemented in a nuclear fuel cycle simulator. It 
allows the core Cyclus framework to operate inde¬ 
pendently from the plug-in libraries, and the dynam¬ 
ically loadable plug-ins to be the primary mechanism 
for extending Cyclus’ capabilities independent of 
the core. 

An additional benefit is the ability for contribu¬ 
tors to choose different distribution and licensing 
strategies for their contributions. Users and model¬ 
ers control the accessibility of their archetypes and 
data sets (See Figure 2.1.2). In particular, since the 
clean plug-in architecture loads libraries without any 
modifications to the Cyclus kernel, closed-source 
archetypes can be used with the simulator alongside 
open source archetypes without transfer of sensitive 
information. This architecture allows closed-source 
libraries (e.g., those representing sensitive nuclear 
processes and subject to export control) to be de¬ 
veloped and licensed privately. 

Finally, dynamically loadable libraries enable Cy¬ 
clus to easily handle varying levels of simulation 
complexity. Hence a single simulation engine can be 
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Figure 1: The CycluS core provides APIs that abstract away 
the details in the kernel and allow the archetypes to be loaded 
into the simulation in a modular fashion. 



Figure 2: The Cyclus framework enables fully open, partially 
open, and fully closed collaborations!^ . 
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used by both users interested in big-picture policy 
questions as well as users focused on detailed tech¬ 
nical analyses. They merely choose their preferred 
level of modeling depth from among the available 
libraries in the ecosystem. 

2.2. Agent-based Paradigm 

Cyclus implements an agent-based modeling 
paradigm. ABM enables model development to 
take place at an agent level rather than a system 
level. In the nuclear fuel cycle context, for example, 
an analyst can design a reactor agent that is entirely 
independent from a fuel fabrication agent. Defining 
the behavior of both agents according to the API 
contract is sufficient for them to interact with one 
another as bona fide agents in the simulation. The 
two archetype libraries can be used in the same 
simulation without any shared knowledge, allowing 
modelers to construct a simulation from building 
blocks of many types and origins. 

Furthermore, the ABM paradigm is more flexi¬ 
ble and intuitive (from both a developer and user 
perspective) than the system dynamic approach 
used in current simulators. System dynamics is a 
popular approach for modeling nuclear fuel cycles 
[371123 Ham]. Formally however, system dynamics 
models are simply a strict subset of agent-based 
models |3]. That is, any system dynamics model 
can be translated into an agent-based model. ABM 
techniques therefore enable a broader range of sim¬ 
ulations in a more generic fashion. 

2.2.1. Agent Interchangeability 

ABM is inherently object-oriented because agents 
represent discrete, independently acting objects. 
Figureillustrates the modular nature of Cy- 
CLUS archetypes. The core of the Cycltjs simu¬ 
lator creates a set of classes on which agent plug¬ 
ins are based. Agent plug-ins utilize the generic 
core APIs that dehne agent-to-agent interaction as 
well as agent-to-environment interaction. For ex¬ 
ample, they use the resource exchange paradigm 
API for trading resources with one another. For 
the archetype developer, these interfaces provide 
enormous power simply. The API abstracts away 
details unnecessary to specifying the archetype be¬ 
havior, while providing all necessary functionality 
for interacting with the Cyclus simulation kernel. 
For the user, multiple archetypes that inherit the 
same APIs are interchangeable in a simulation. 


Critically, this novel functionality enables the com¬ 
parison between agent implementations. For exam¬ 
ple, an archetype that inherits the Region interface, 
as in Figure is interchangeable with any other 
Region agent. 

I cyclus::5tateWrangler j cyclus:;lder I 


cyclus;:Agent 


cyclus::Facility cyclus;:Agent cyclus::Region 


cyclus::DLtmmy 


Figure 3: Inheriting CycluS class interfaces, such as the 
Agent, Facility, Institution, and Region classes, abstracts 
away unnecessary details while exposing powerful function¬ 
ality. In the above example, the Dummy archetype simply 
inherits from Region in order to become a bona fide Region- 
type Agent. 

In this way, a researcher can directly compare 
two different reactor modeling implementations 
(perhaps the imaginary classes DetailedReactor 
and SimpleReactor) simply by exchanging the two 
corresponding archetypes. That is, two reactor 
archetypes both inheriting from the Facility class 
are indistinguishable from a simulation perspective. 
This can be done with any agent type, where agents 
can be “Regions,” “Institutions,” or “Facilities.” 

2.2.2. Regions, Institutions, and Facilities 

Cyclus provides a novel representation of enti¬ 
ties in the nuclear fuel cycle that reflects the reality 
in international nuclear power: facilities implement¬ 
ing individual fuel cycle technologies, institutions 
managing those facilities, and regions providing ge¬ 
ographical and political context for institutions and 
facilities. While few simulators have provided any 
notion of static regional effects mm. Cyclus al¬ 
lows for both regions and institutions to be first- 
class agents in simulated fuel cycles. The funda¬ 
mental interactions for each entity are implemented 
in a corresponding archetype class in Cyclus, i.e., 
the Region class. Institution class, and Facil¬ 
ity class. Archetype developers can then build on 
the provided functionality by inheriting from the 
appropriate class. Cyclus implements a Region- 
Institution-Facility (RIF) relationship through a 
parent-child hierarchy where regions are the parents 
of institutions which are, in turn, the parents of 
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facilities. In other words, RIF hierarchies form a 
directed acyclic graph (DAG|^ with regions as root 
nodes and facilities as leaf nodes. 

Two primary consequences arise from this struc¬ 
ture. First, institutions are nominally responsible 
for deploying and decommissioning facilities. Ac¬ 
cordingly, advanced logic regarding building and de¬ 
commissioning can be implemented on top of those 
behaviors inherited from the Institution interface. 
Second, the Facility class implements the Trader 
interface to participate in resource exchange, and 
institutions and regions, respectively, can adjust the 
resource flow preferences of their managed facilities. 
Importantly, this capability allows for the modeling 
of preferential regional trading of resources (e.g., 
tariffs) as well as preferential institutional trading 
(e.g., long-term contracts). 

2.3. Discrete Objects 


2.3.1. Resources and Materials 

Another such use case seeks to capture system 
vulnerability to material diversion. Provenance and 
trade-history of distinct materials is the fundamental 
information unit in such studies, and so this type 
of analysis requires discrete simulation of a target 
facility and the individual materials modified within 
it. Material risk analysis, therefore, demands that 
both facilities and materials should be discretely 
modeled objects like those in Cyclus. 

In Cyclus, agents can transfer discrete resource 
objects among one another. Cyclus supports two 
types of resources: 

• materials: these represent typical nuclear ma¬ 
terials with nuclide compositions; 

• products: these can represent any user-defined 
measure: carbon credits, build permits, employ¬ 
ees, etc.. 


Cyclus models facilities, institutions, regions, 
and resources as discrete objects. A discrete re¬ 
source model allows for a range of modeling granu¬ 
larity. In the macroscopic extreme, it is equivalent 
to time-stepped continuous flow. In the microscopic 
extreme, the model is capable of representing arbi¬ 
trarily small material objects at isotopic resolution. 
In this way, Cyclus is applicable across the full 
range of modeling fidelity. 

Fleet-based, lumped-material models do not dis¬ 
tinguish between discrete facility entities or materi¬ 
als. However, some questions require resolution at 
the level of individual facilities and materials. As 
a result, many detailed performance metrics can¬ 
not be captured with previously existing fleet-based 
models. For example, meaningful models of spent 
nuclear fuel storage transport, and disposal strate¬ 
gies, require representation of discrete casks and 
their varying isotopic compositions. 

For all of the reasons that the ABM paradigm 


2.2 enables novel simulations, multiple use cases 


require that these agents, such as the regions, institu¬ 
tions, and facilities in Cyclus, must be represented 
as discrete objects. For instance, tracking of in¬ 
dividual shipments is only viable if materials and 
resources are tracked as discrete objects. 


^ DAGs are common graph theoretic structures whose 
most important feature is a lack of cycles, i.e., there is a 
single path from the root node to any other node in the 
graph. 


All operations performed on every resource ob- 
ject (splitting, combining, decay, etc.) are tracked 
in detail as they are performed. This information 
includes the agent that created each resource when 
it was introduced into the simulation. The parent¬ 
age of each resource is also tracked. This makes it 
possible to follow the history of resources as they 
are transferred between agents. 

The Cyclus kernel has built-in experimental sup¬ 
port for decay calculations. Materials store the time 
since their last decay and agents are free to invoke 
the decay function on them as desired to decay them 
to the current simulation time. Cyclus can operate 
in 3 decay modes, with 1 additional mode likely to 
be added in a future release: 

• “manual” (currently implemented) is the de¬ 
fault mode where agents decay materials when 
requested by an archetype, 

• “never” (currently implemented) globally turns 
off all decay. The Material decay function does 
nothing, 

• “lazy” (currently implemented) decays material 
automatically whenever its composition is ob¬ 
served (e.g. when an agent queries information 
about a material’s ^^®Pu content), 

• “periodic” (future) automatically decays all 
materials in a simulation with some fixed fre¬ 
quency. 
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When decay is invoked, a material checks to see 
if it contains any nuclides with decay constants 
that are significant with respect to the time change 
since the last decay operation. If none of the decay 
constants are significant, no decay calculation is per¬ 
formed and the material remains unchanged. This 
error does not accumulate because the next time 
the material’s decay function is invoked, the time 
change will be larger. 

Cyclus has no notion of “tracked” versus “un¬ 
tracked” nuclides. In Cyclus, the composition of a 
material is represented by an arbitrarily large list 
(potentially thousands) of nuclides. Agents are free 
to treat nuclides present in materials any way they 
please - including ignoring them. It is the respon¬ 
sibility of archetype developers to choose how to 
handle potentially full-fidelity compositions. 

In large simulations, many material objects may 
change frequently. Material decay can also con¬ 
tribute significantly to such changes. In order to 
help avoid unnecessary runtime performance and 
database size impacts, compositions in Cyclus have 
some special features. In particular, compositions 
are immutable once created. This allows multi¬ 
ple material objects to hold references to the same 
composition safely. Additionally, new compositions 
resulting from decay are cached and used to avoid 
redundant decay calculations. Figure illustrates 
how this decay history cache works. Composition 
immutability in concert with decay history caching 
help eliminate many redundant calculations in ad¬ 
dition to reducing the total number of composition 
entries recorded in the database. 

2.3.2. Dynamic Resource Exchange (DRE) 

The Cyclus simulation paradigm allows discrete 
agents, based on archetypes about which the kernel 
has no knowledge, to enter the simulation at arbi¬ 
trary times and trade in discrete resources. These 
resources are not defined a priori. Therefore, the 
logic engine defining resource interaction mecha¬ 
nisms among agents is crucial. The DRE, described 
in detail in |35| , is that critical logic engine on which 
Cyclus simulations are built. Supporting the gen¬ 
eral Cyclus philosophy, facilities are treated as 
black boxes and a supply-demand communication 
framework is defined. 

The DRE consists of three steps: supply-demand 
information gathering, resource exchange solution, 
and trade execution. Importantly, each step is ag¬ 
nostic with respect to the exchange of resources in 



Figure 4: A simple decay line cache holding compositions 

A, B, C, and a yet-uncomputed composition D. B comes 
from decaying A 1 time step. C comes from decaying B 2 
time steps, etc. Black represents the cache for this particular 
composition chain. Blue indicates decay operations that can 
be satisfied by cache lookups. If A needs to be decayed 1 time 
step (A +1), a quick lookup returns the previously computed 

B. Decaying B 3 time steps requires a decay calculation to 
compute a new composition D, but subsequent requests such 
as decaying A 4 time steps will not require any recalculation. 

question, i.e., the same procedure is used for both 
Materials and Products. 

The information-gathering step begins by polling 
potential consumers. Agents define both the quan¬ 
tity of a commodity they need to consume as well 
as the target isotopics, or quality, by posting their 
demand to the market exchange as a series of re¬ 
quests. Users may optionally parameterize the agent 
to associate a collection of demand constraints with 
each collection of requests. Collections of requests 
may be grouped together, denoting mutual requests 
that represent demand for some common purpose. 
For example, a reactor may request UOX and MOX 
fuel mutually, indicating that either will satisfy its 
demand for fuel. 

Suppliers then respond to the series of requests 
with a bid. A bid supplies a notion of the quantity 
and quality of a resource to match a request. Sup¬ 
pliers may add an arbitrary number of constraints 
to accompany bids. For example, an enriched UOX 
supplier may be constrained by its current inventory 
of natural uranium or its total capacity to provide 
enrichment in Separative Work Units (SWUs). It 
attaches such constraints to its bids. 

Any potential resource transfer, i.e., a bid or a 
request, may be denoted as exclusive. An exclusive 
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transfer excludes partial fulfilment; it must either be 
met fully or not at all. This mode supports concepts 
such as the trading of individual reactor assemblies. 
In combination with the notion of mutual requests, 
complex instances of supply and demand are en¬ 
abled. 

Finally, requesting facilities, institutions and 
regions may apply preferences to each potential 
request-bid pairing based on the proposed resource 
transfer. Facilities can apply arbitrary complex logic 
to rank the bids that they have received, whether 
based on the quantity available in each bid or on the 
quality of each bid, and the consequent implications 
of the physics behavior of that facility. In addition, 
an institution can apply a higher preference to a 
partner to which it is congenial; similarly, a region 
may negate any transfers of material which have a 
higher uranium enrichment than is allowable. 



Figure 5: The flow graph representing three suppliers (left), 
two requesters (right), and the potential flows of various 
commodities among them. The second consumer makes 
two different requests. Meanwhile, the second supplier can 
supply the commodities requested by both consumers and 
has provided two bids accordingly m- 

Given a full dehnition of supply and demand, rep¬ 
resented in Figure as a flow graph, the DRE may 
be solved either optimally using a mathematical 
program or approximately by a simulation-based 
heuristic [35]. If any trade is denoted as exclusive, 
e.g., if an analyst desires an assembly-fidelity model, 
then either a heuristic must be used or exchanges 
must be represented as a mixed-integer linear pro¬ 
gram (MILP). If no exclusive trades exist, a linear 
program (LP) model may be used. The LP formu¬ 
lation in Cyclus is of the form given by Gidden 



In practice, LPs solve much faster than MILPs. 
However, both capabilities exist in Cyclus in order 
to provide users with the desired level of hdelity. 

Trades between agents are initiated by the Cy¬ 
clus kernel after a solution to the DRE is found. 
For each trade, the supplying agent is notified of 
its matched request and provides an associated re¬ 
source to the exchange. All supplied resources are 
then sent to the corresponding requesting agents. 

In Cyclus, the DRE is executed at each time 
step. Therefore, if a facility’s request for a resource 
is not met at a given time step, it may offer a request 
in the following time step. Because agent behavior 
may change arbitrarily, the exchange executed at 
any given time step may be unique in a simulation. 

The DRE is a novel simulation concept in the 
nuclear fuel cycle domain. It provides a flexible 
supply-demand infrastructure, supporting dynamic 
flows of resources between agents, even as those 
agents enter and leave the simulation, and even when 
those agents are defined by archetypes of arbitrary 
complexity. Trading between agents can be affected 
by both the proposed quality of a resource and 
agent relationships through the use of preferences. 
Accordingly, a wide range of possible effects can 
be modeled, from capacity-limited fuel supply to 
international trade agreements. 

2.4- Simulation Support 

So that users and developers can build work¬ 
ing simulations in the shortest time possible, the 


min z = c^x (1) 

X 

s.t. Ax < b (2) 

Xij e [0,ij] Vi e J, Vj e J (3) 

where 

I = set of supply nodes 
J = set of request nodes 
Ci^j = unit cost of flow from i to j 
Xij = flow from node i to node j 
a!l j = coefficient for constraint k between i and j 

= RHS for constraint k for a given supplier or requester 
Xj = requested quantity of request node j. 
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Cyclus ecosystem provides fundamental building 
blocks: basic archetypes and a toolkit of commonly 
needed functions. The Cycamore library provides 
a suite of fundamental Region, Institution, and Fa¬ 
cility archetypes, while the Cyclus toolkit provides 
assistance to developers. 


2.4-1- Cycamore 

Cycamore [3H], the Cycles additional module 
repository, provides a fundamental set of dynami¬ 
cally loadable libraries providing agent archetypes 
for basic simulation functionality within Cycles. 
Since Cycles relies on external archetypes to repre¬ 
sent the agents within a simulation, Cycamore 
provides the basic archetypes a new user needs 
to get started running simple simulations. These 
archetypes support a minimal set of fuel cycle sim¬ 
ulation goals and provide, by example, a guide to 
new developers who would seek to contribute their 
own archetypes outside of Cycamore. 

As of version 1.0, Cycamore contains one region 
archetype, two institution archetypes, and four fa¬ 
cility archetypes. Three additional facilities were 
added in version 1.3 . Short descriptions of these 
functions can be found in Table [TJ 

Section 13.21 will demonstrate how the current 
Cycamore release provides basic functionality en¬ 
abling simple fuel cycle analyses. As future contri¬ 
butions are vetted, the capabilities in Cycamore 
may grow. 


2.4-2. Toolkit 

In addition to the core functionality of the Cy¬ 
cles kernel, which is focused on the set of capabili¬ 
ties needed to implement an agent-based simulation 
with DRE, a toolkit is provided to assist developers 
and users with related simulation and nuclear engi¬ 
neering tasks. The toolkit is an actively developed 
part of Cycles, with a primarily forward-looking fo¬ 
cus on supporting interesting in situ metric analysis 
tools. 

Simulation Tools. A series of utility classes are pro¬ 
vided to support demand-constrained agent facility 
deployment. For example, symbolic function rep¬ 
resentations of linear, exponential, and piecewise 
functions are supported via the SymbFunctionFac- 
tory class. Such functions are used with other 
toolkit classes to determine commodity demand 
(e.g., power demand) from user input. Four mix-in 


classes provide the basis for in-simulation deploy¬ 
ment determination: CommodityProducer, Commod- 
ityProducerManager, Builder, BuildingManager. 
The CommodityProducer class provides an interface 
for querying the prototypes which have the capacity 
to produce a given commodity. The CommodityPro- 
ducerManager provides an interface for registering 
CommodityProducers and querying the current ca¬ 
pacity (supply) of a commodity. The Builder class 
provides an interface for querying which prototypes 
can be built and interacts with the BuildingMaui- 
ager, which orders prototypes to be built. The 
BuildingMcinager uses a simple minimum cost al¬ 
gorithm to determine how many of each prototype. 
Pi, to build given a demand ($), capacities {4>i), 
and costs (ci). Here i indexes / available proto¬ 
types which perform a similar function, and the 
demand, capacity and cost carry prototype-specific 
units which are defined by the developer. 


N 

min^Ci2/i 

N 

s.t.'^4)iyi > $ 

Z=1 


Pi G [0, oo) V* G /, Pi integer 


(4) 


Nuclear Engineering Tools. The Cycles toolkit 
provides two useful interfaces for querying physical 
parameters of Material objects. First, the Mat- 
Query tool provides a basic querying API, including 
the atom and mass fractions of nuclides, the num¬ 
ber of moles of a nuclide in a material, etc. (i.e., a 
Composition), in a material. The Enrichment tool 
provides an API for determining enrichment-related 
parameters of a material, including the SWU and 
natural uranium required to enrich a material pro¬ 
vided knowledge of feed, product, and tails assays. 


Toolkit Extensions. In addition to those that al¬ 
ready exist, new tools will emerge from the 
archetypes developed by the community. As these 
tools gain adoption between projects and demon¬ 
strate their utility to the developer community, they 
will be considered for screening and adoption into 
the kernel as toolkit extensions. Likely extensions 
include 


• fuel cycle metrics calculators, 

• supportive data tables, 

• policy models. 
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Entity 

Archetype 

Functionality 

Facility 

EnrichmentFacility 

This facility enriches uranium at a specified capacity. 

Facility 

Fab* 

This facility fabricates fuel material based on separated streams. 

Facility 

Reactor* 

A reactor model that handles batch refueling, based on pre-determined 
recipes of compositions. It requests any number of input fuel types 
and transmutes them to static compositions upon discharge. 

Facility 

Separations* 

This facility separates an incoming material into specified streams. 

Facility 

Sink 

This facility is capable of accepting a finite or infinite quantity of some 
commodity produced in the simulation. 

Facility 

Source 

This facility generates material of the composition and commodity 
type specified as input. 

Institution 

Managerinst 

The manager institution manages production of commodities among 
its facilities by building new ones as needed. 

Institution 

Deployinst 

This institution deploys specific facilities as defined explicitly in the 
input file. 

Region 

GrowthRegion 

This region determines whether there is a need to meet a certain 
capacity (as defined via input) at each time step. 


Table 1: The Archetypes in Cycamore seek to cover a large range of simple simulation use cases m- Facilities added in version 
1.3 are marked with *. 


• and economic models. 

2.5. Quality Assurance 

To garner the trust of a broad user and archetype 
developer community, the Cyclus project must im¬ 
plement a strategy to assure the ongoing quality of 
the software it provides. Multiple strategies, collec¬ 
tively known as quality assurance ( QA have been 
developed by the scientific software development 
community to mitigate structural and algorithmic 
errors in software. These include verification and 
validation (V&V) [SH], testing, and others. 

Nuclear engineering software quality is often gov¬ 
erned by Nuclear Quality Assurance - 1 (NQA-1), an 
American Society of Mechanical Engineers (ASME) 
specification whose latest revision appeared in 2009 
PU] . Cyclus has adopted an agile development pro¬ 
cess lu, interpreting NQA-1 in a manner similar 
to the process adopted by the Department of En¬ 
ergy (DOE) within Nuclear Engineering Advanced 
Modeling and Simulation (NEAMS) [42] or by the 
PyNE toolkit [43]. 

Validation of simulators like Cyclus, that are 
intended to give forecasts of system behavior in 
uncertain futures, is not well defined as there are 
no experimental benchmarks upon which to rely. 
Instead, code-to-code comparisons with fuel cycle 
simulators that use other modeling paradigms are 
underway as the best approach to establish confi¬ 
dence that Cyclus produces correct answers. jUj 


Verficiation of Cyclus implementation relies on 
software development best practices such as version 
control, testing, continuous integration, documenta¬ 
tion, and style guidelines to ensure reliability and re¬ 
producibility. Sections 2.5.1|2.5.3 discuss in greater 
detail the software development components that 
comprise the Cyclus verification strategy, which 
allows the simulation kernel and physics models to 
be tested explicitly and separately. Each of these ap¬ 
proaches on its own is a valuable addition to QA but 
it cannot be the entire answer to the requirements 
imposed by NQA-1. Taken together and strictly ad¬ 
hered to, they present a fortress to protect against 
poorly designed or otherwise undesirable code. 


2.5.1. Version Control 

Automated version control, provided by git, a 
well-established distributed version control tool [45] . 
is at the heart of the QA strategy because it records 
the full history of any change, along with metadata 
such as the author, a timestamp, and an accompany¬ 
ing message. This makes it possible to identify when 
changes were introduced, how they are related to 
other changes, and who made those changes. If nec¬ 
essary, it also facilitates reversing individual changes 
from a long and intricate set of changes. Version 
control also enables a code review process descried 
in section 12.5.31 below. 
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2.5.2. Testing 

Automated software testing is the first line of 
defense against errors in implementation. Testing 
directly compares the actual results of running soft¬ 
ware versus the expected behavior of the software. 
In Cyclus, three categories of tests are defined: 
unit tests, integration tests, and regression tests. 
Before a proposed code change is allowed into Cy- 
CLUS, the change must be covered by a test, either 
new or existing, and all tests must pass. 

Unit Tests. Unit tests verify behavior of the small¬ 
est code unit, typically a single function or a class. 
Cyclus uses the Google Test framework [35] as a 
harness for running unit tests. Sufficient unit tests 
are required for any proposed change to the Cyclus 
code base. Currently, Cyclus implements over 450 
unit tests and Cycamore implements 85. These 
cover approximately 65% of their respective code 
bases, and these numbers are expected to grow over 
time. 

Integration Tests. Integration tests combine multi¬ 
ple elements of the Cyclus interface and test that 
they work correctly with each other. In Cyclus 
and Cycamore, integration tests are performed by 
running sample simulations for scenarios verifying 
that results match predictions. A set of standard 
input files are run, then the output is inspected and 
compared via Nose 07], a Python test framework. 

Regression Tests. Regression tests ensure significant 
unintended changes do not occur over the course 
of Cyclus development. Regression tests are im¬ 
plemented similarly to integration tests. In this 
category, however, the comparison is done against 
the output of the same input file when run with a 
previous version of Cyclus, typically the last re¬ 
leased version. In some sense, regression tests are 
‘dumb’ in that they do not care about the contents 
of a simulation being correct, only whether or not 
it changed. 

Continuous Integration. Continuous integration 
(Cl) is the idea that software should be automati¬ 
cally tested and validated as it is being developed, 
rather than as a final stage in a longer development 
cycle. The results of this testing are shown to code 
reviewers prior to reviewing the software changes 
themselves. The Cyclus project uses the Circled 
[48] service for continuous integration. When a code 
change is submitted for review. Circled builds a 


version of the Cyclus source code that includes 
the requested changes and runs the complete test 
suite, reporting back whether or not those steps 
were successful. If Cl was not successful, the code 
author(s) must first identify and resolve the prob¬ 
lems. These steps are performed for all incoming 
code prior to inclusion, so broken code never enters 
the main software development branch. 


2.5.3. Code Review 

Automated testing including Cl is a necessary 
but not sufficient component of the Cyclus QA 
system: it keeps bad code out of Cyclus. However, 
Cyclus will always require human eyes and hands 
to let good code in. 

The main Cyclus repository is hosted remotely 
and publicly on the GitHub website [35], in part 
because it provides tools that facilitate a culture 
of frequent and thorough code review. A number 
of policies exist to ensure that a proposed set of 
changes, known as a pull request, adhere to the 
projects QA standards. Every pull request must be 
reviewed and accepted by a member of the Gyclus 
core team that was not involved in authoring the 
changes. In addition to reviewing the algoirthmic 
design in the source code, the reviewer relies on tests 
to ensure correct behavior, and requires the authors 
to adhere to the style guide and provide sufficient 
documentation. Only after the QA standards have 
been met are the proposed changes merged into the 
software. This step has been repeatedly shown to 
improve code quality |3]. 

Once Cl is successful, a code reviewer inspects not 
only the changes that are proposed to the software 
itself, but also the changes that have been proposed 
to tests. 

Because of their long term benefit to the main¬ 
tainability of the project, documentation and coding 
style are also reviewed as part of this process. The 
API must be documented as required by the Cy¬ 
clus QA policy. In Cyclus, this information is 
aggregated together into static websites with the 
Doxygen |5nj and Sphinx m tools, and can be 
accessed at http://fuelcycle.org, Cyclus also 
strictly enforces the use of the Google C-|—I- Style 
Guide |S3] for all software contributions. This means 
that all developers of Cyclus write Cyclus code 
in the same way. This homogenization may be a 
hurdle to new developers but ultimately improves 
code legibility and, therefore, robustness [3]. 
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3. Demonstration 

The success of the Cyclus simulator can be mea¬ 
sured in many ways. The most compelling are 
early successes of the community-driven develop¬ 
ment model and demonstrations of its fundamen¬ 
tal simulation capabilities. Promising growth of 
the Cyclus ecosystem at multiple institutions in¬ 
dicates that a fuel cycle simulator can advance in 
this community-driven development paradigm. Ad¬ 
ditionally, simulation results for both once-through 
and more complex recycling scenarios demonstrate 
that Cyclus possesses the fundamental fuel cycle 
simulation capabilities to contribute to the field. 

3.1. Ecosystem 

The Cyclus community-driven software devel¬ 
opment model seeks to break the proliferation of 
specialized simulators. It instead leverages the col¬ 
lective expertise of fuel cycle researchers toward a 
single, more extensible, tool. Through the targeted 
contributions of those researchers, an ecosystem of 
capabilities should emerge. The Cyclus ‘Ecosys¬ 
tem’ is the collection of tools, calculation libraries, 
archetypes, data, and input files intended for use 
with the Cyclus simulator. Members of the ecosys¬ 
tem include: 

• the archetypes provided in the Cycamore [55] 
repository 

• the archetypes created by researchers 

• isotopic composition data 

• historical facility deployment data 

• the Cyclus graphical user interface (GUI) tool 
Cyclist 

• fundamental analysis tools in the Cyclus 
toolkit 

• tools for Cyclus optimization, parallelization, 
and development 

Taken together, these form an ecosystem of capa¬ 
bilities. Over time, this ecosystem will grow as 
archetype developers, kernel developers, and even 
users contribute capabilities developed for their own 
needs. Indeed, the long-term vision for the Cyclus 
framework predicts an ever-expanding ecosystem of 
both general and specialized capability extensions. 


Already, the ecosystem is growing. Early cross- 
institutional contributions to the ecosystem demon¬ 
strate a significant achievement by the Cyclus 
framework and provide the basis for a community- 
driven development model. 

3.1.1. Supplementary Projects 

A number of projects and tools outside of the 
core simulation kernel have been developed to im¬ 
prove the scope and the diversity of the capabilities 
in the Cyclus ecosystem. Table lists the tools 
and projects developed under close integration with 
the Cyclus kernel. These tools are used to ease 
development and simulation design (Cycstub, Cy- 
cic, Ciclus), data visualization and analysis (Cyclist, 
Cyan), and remote execution (Cloudlus). 

3.1.2. Archetype Contributions 

It is expected that the most common type of 
contribution to Cyclus will be contributions of new 
archetypes. Researchers will be driven to create a 
new archetype when a need arises, such as to improve 
the fidelity of simulation, or to represent a novel 
reactor type, an innovative reprocessing strategy, or 
a particular governmental or institutional behavior. 
The real-world utility of Cyclus can in part be 
measured by the breadth and diversity of archetypes 
being developed in this way. 

Early progress has been promising. Many 
archetypes external to the Cycamore library (Ta¬ 
ble have been [59l [60] or are being iniMiEs] 
developed for contribution to the Cyclus ecosys¬ 
tem. These archetypes provide the first examples of 
developer-contributed capabilities. They add to the 
fundamental Cycamore archetypes by providing 
physics-based reactors, separations logic, fuel fabri¬ 
cation processing, storage facilities, and expanded 
institutional paradigms. The existence and diversity 
of these contributed archetypes illustrate the power 
and potential of the community-based development 
approach that Cyclus has taken. 

3.2. Simulations 

To illustrate the flexibility of Cyclus, this sec¬ 
tion will discuss the creation and results of a range 
of representative fuel cycle simulations. Previous 
benchmarks between Cyclus and system dynamics 
simulators for more complex problems, including 
transition analyses, have been reported elsewhere 
and Cyclus has demonstrated satisfactory perfor¬ 
mance [511153133155| . The examples presented here 
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Name Description Ref. 


Cycic Input control embedded in Cyclist [S3] 

Cyclist Interactive data exploration environment |54j 

Ciclus Continuous integration scripts for Cyclus jSSj 

Cycstub Skeleton for clean slate module development jSSj 

Cyan Cyclus analysis tool m 

Cloudlus Tools for running Cyclus in a cloud environment |S8| 


Table 2: Many tools have been developed outside of the scope of the Cyclus kernel for improved user, developer, and analyst 
experiences with CycluS. 


Name Description Ref. 

Bright-lite A physics-based reactor archetype and fuel fabrication archetype |6l] 

Nuclear Fuel Inventory Model A flexible, ORIGEN-based, reactor analysis module |S3] 

CommodConverter A simple commodity converting storage facility archetype m 

MktDrivenInst An institution that controls deployment based on commodity |63j 
availability 

SeparationsMatrix A facility for elemental separations of used fuel |59| 

StreamBlender A facility for fuel fabrication from reprocessed streams jSS] 


Table 3: A diverse set of archetypes under development reflect the diverse needs of researchers at various institutions. These 
archetypes, contributed outside of the Cyclus core and Cycamore libraries are the first demonstration of community-driven 
development in a fuel cycle simulator. 


are not the limit of Cyclus’ capabilities, which are 
extended with each new addition to the ecosystem, 
as discussed above. Rather, these simulations are 
designed to illustrate that Cyclus matches the ca¬ 
pabilities of any recipe-based simulator and that 
variations on a single Cyclus simulations can be 
run with small changes to the input specification. 
For simplicity of the current demonstration, many 
simplifying assumptions have been made with re¬ 
spect to material compositions, fuel transmutation, 
among others. The three fuel cycles examined are: 

1. No Recycle (once through) 

2. 1-pass MOX Recycle 

3. Infinite-pass MOX Recycle 

For each of these fuel cycles, a 1,100 month single¬ 
reactor Cyclus simulation was run in addition to a 
10-reactor simulation with staggered refueling times. 
As the number of staggered-cycle reactors increases 
the system converges toward continuous material 
flow results. Cyclus flexibility allows this transition 
to be examined. 
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Facility 

Parameter 

Value 

LWR 

type 

LWR 

cycamiore; : Reactor 

batches 

3 [batches/cycle] 


batch size 

20 [MTHM] 


cycle length 

18 [months] 


refuelling time 

2 [months] 


requests 

recycled MOX (1st preference) 


requests 

enriched UOX (2nd preference) 

Spent Fuel Fabrication 

requests 

depleted uranium 

cycamore::Fab 

requests 

separated fissile material 


offers 

recycled MOX 

Separations 

requests 

all spent fuel types 

cyccunore: : Separations 

offers 

separated fissile material 


efficiency 

0.99 


Pu separation capacity 

6.0if4 [kg/month] 

Repository 

requests 

all waste 

cycamore;:Sink 

capacity 

oo 

UOX Fabrication 

offers 

UOX 

cycamiore; : Source 

capacity 

oo 

DU Source 

offers 

depleted U 

cyccunore: : Source 

capacity 

oo 


Table 4: Facility Configurations for Example Simulations 
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As described in Table the facilities used in these 
simulations are: 


• Reactor (cycamore: :Reactor): This is a re¬ 
actor model that requests any number of input 
fuel types and transmutes them to static com¬ 
positions when they are burnt and discharged 
from the core. The reactor was configured to 
model a light water reactor with a 3 batch core 
operating on an 18 month cycle with a 2 month 
refuel time. The batches in the core each con¬ 
tain 20 metric tons of heavy metal (MTHM), 
where heavy metals are actinide elements like 
thorium, uranium, and plutonium. The reactor 
was also configured to take in either enriched 
UOX fuel or recycled MOX fuel. 


• Spent Fuel Fabrication (cycamore::Fab): 
This facility requests depleted uranium and 
separated fissile material and mixes them to¬ 
gether into recycled MOX fuel that it offers to 
requesters. The two streams are mixed in a 
ratio in order to match simple neutronics prop¬ 
erties of the target fuel as closely as possible. 
The method used is based on a variation “equiv¬ 
alence method” originally developed by Baker 
and Ross j67j. This technique has also been 
used in the COSI fuel cycle simulator devel¬ 


oped by the French Commissariat a I’Energie 
Atomique et aux Energies Alternatives (CEA). 

• Separations (cycamore :: Separations): 
This facility takes in all kinds of spent fuel and 
separates it into plutonium and waste streams 
with some efficiency (0.99 was used for these 
simulations). Up to 60,000 kg of Pu can be 
separated per month. 

• Repository (cycamore:: Sink): This is an 
infinite-capacity facility that can take in all 
types of material including separations waste 
streams and spent reactor fuel. 

• UOX Fabrication (cycamore:: Source): 
This facility provides enriched UOX fuel as 
requested. This facility has infinite production 
capacity. 

• DU Source (cyccunore: : Source): This facil¬ 
ity provides depleted uranium as requested. 
This facility has infinite production capacity. 

To model each of the three fuel cycles, only simple 
adjustments to the input file specification were nec¬ 
essary. Specifically, only the commodity types and 
trade preferences for each of the facilities needed to 
be altered from one simulation to another. 

For all cases, the reactor was configured to re¬ 
quest recycled MOX fuel with a higher preference 
than new UOX fuel. For the No Recycle case, the 
Reactor was set to offer all spent fuel as waste. For 
the 1-pass recycle case, the Reactor offered spent 
UOX into a spent fuel market, but spent MOX is 
still offered as waste. In the Inhnite-Pass Recycle 
case, the Reactor offers all burned fuel into a spent 
fuel market. The separations facility requests spent 
fuel with a higher preference than the repository re¬ 
sulting in preferential recycle. All these preferences 
are easy to adjust and Cyclus dynamically handles 
supply constraints and non-uniform preference res¬ 
olution. It is notable that separations and recycle 
fuel fabrication capacity are deployed identically in 
all simulations. In the once through case, the recy¬ 
cling loop never acquires material, and so reactors 
always receive fresh UOX fuel. The DRE ensures 
everything operates smoothly in all cases. 

Cyclus’ discrete materials make single-pass re¬ 
cycle straightforward to implement. The reactors 
keep track of fuel as discrete batches. A reactor 
remembers where it received each batch from. If a 
batch was received from the recycled fuel fabrica¬ 
tion facility, it does not offer it to separations and 
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Figure 6: 1-pass MOX recycle scenario material flows. 

instead offers it as a waste commodity which is only 
requested by the repository. The material flows for 
the Single-Pass Recycle case are shown in Figure 
Changing the scenario from a 1-pass fuel cycle 
to an infinite-pass fuel cycle requires only a one- 
word change in the input file regarding the output 
commodity for the spent MOX fuel of the Reactor: 

<fuel> 

< incommodity >inox </ incommodity > 

<outcommodity >waste</outcommodity > 

+ < out commodity >spent_fuel</out commodity > 

<inrecipe >mox_fresh_fuel</inrecipe > 
<outrecipe>mox_spent_fuel</outrecipe> 

</fuel> 

This results in the material flows in Figure A 
similarly trivial change was used to switch from 
the No Recycle to a 1-pass fuel cycle. Note that 
because the reactors always transmute fuel into fixed 
compositions, the error in isotopic compositions is 
larger for the Infinite-Pass Recycle case. 

Figure shows the full-system plutonium buildup 
for No Recycle (once through), Single-Pass Recy¬ 
cle, and Infinite-Pass Recycle variations of the one- 
reactor scenario described above. The figure was 
generated directly from Cyclus output data. After 
several batch cycles (near month 300) in the I-pass 



Figure 7: Full MOX recycle (multi-pass) fuel cycle material 
flows. 

and infinite-pass cases, enough separated fissile ma¬ 
terial accumulates in the fuel fabrication facility to 
generate a full recycled batch. When this batch is 
transmuted, more plutonium is burned than created. 
This results in a drop in the total fuel cycle system 
plutonium inventory. This pattern repeats roughly 
every 10 cycles (200 months) for the Single-Pass 
Recycle case and every 9 cycles (180 months) for 
the Infinite-Pass Recycle case. Because the 1-pass 
recycle scenario does not re-recycle material, it takes 
the fabrication facility 2 cycles longer to accumulate 
a full batch of fissile material. 

Because facilities are represented individually and 
transact discrete materials as discrete events, real¬ 
istic non-uniform patterns in facility behavior that 
affect total system behavior are observed using Cy- 
CLUS. 

Figure shows plutonium buildup for the 10- 
reactor simulations of the No Recycle, Single-Pass 
Recycle, and Infinite-Pass Recycle scenarios. As 
the number of reactors (with staggered refueling) 
increases, the behavior of the system approaches 
a more steady average reminiscent of continuous 
material flow models. 

The fundamental capabilities of demonstrated in 
these simulations qualify Cyclus and its ecosystem 
to model the breadth of scenario types expected of 


18 

























Figure 8: System plutonium buildup with one reactor. 



Figure 9: System plutonium buildup with staggered refueling 
for many reactors. 

nuclear fuel cycle simulator tools. These examples 
further show the flexibility provided by the DRE 
logic within the Cyclus framework and provide an 
example of the resolution made possible by discrete- 
facility and discrete-material modeling in fuel cycle 
simulation. 

4. Conclusions 

The Cyclus nuclear fuel cycle framework 
presents a more generic and flexible alternative to ex¬ 
isting fuel cycle simulators. Where previous nuclear 
fuel cycle simulators have had limited distribution, 
constrained simulation capabilities, and restricted 
customizability, Cyclus emphasizes an open strat¬ 
egy for access and development. This open strategy 
not only improves accessibility, but also enables 


transparency and community oversight. Further¬ 
more, the object-oriented ABM simulation paradigm 
ensures more generic simulation capability. It allows 
Cyclus to address common analyses in a more flexi¬ 
ble fashion and enables analyses that are impossible 
with system dynamics simulators. 

Similarly, the fidelity-agnostic, modular Cyclus 
architecture facilitates simulations at every level of 
detail. Simulations relying on arbitrarily complex 
isotopic compositions are possible in Cyclus, as 
are simulations not employing any physics at all. 
Physics is introduced through optional system-wide 
radioactive decay of materials and through the use 
of physics-enabled facility libraries. To support cal¬ 
culation of physical processes in nuclear facilities, 
the Cycamore library provides models employing 
basic physics for core fuel cycle facilities and ex¬ 
tension libraries from the community support more 
detailed simulations. Indeed, agents of such varying 
fidelity can even exist in the same simulation. Re¬ 
searchers no longer need to reinvent the underlying 
simulator framework in order to model a simulation 
focused on the aspects of the fuel cycle relevant to 
their research. 

Furthermore, when the capabilities within Cy¬ 
clus, Cycamore, and the rest of the ecosystem 
are insufficient, adding custom functionality is sim¬ 
plified by a modular, plug-in architecture. A clean, 
modern API simplifies customization and indepen¬ 
dent archetype development so that researchers can 
create models within their domain of expertise with¬ 
out modifying the core simulation kernel. Through¬ 
out the Cyclus infrastructure, architecture choices 
have sought to enable cross-institutional collabo¬ 
ration and sustainable, community-driven develop¬ 
ment. The ecosystem of capabilities, already grow¬ 
ing, may someday reflect the full diversity of use 
cases in the nuclear fuel cycle simulation domain. 
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